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I . INTRODUCTION 



The rapid expansion of information systems and networks in the 
command and control world have made them a critical link in the national 
defense. "Computers' . . . speed and unfailing accuracy make them well 
suited to the massive information handling tasks in battle management 
for: shared information storage, retrieval, and dissemination systems; 
rapid and common data processing systems; and efficient and reliable 
communications process control." [Ref. l:p. 271] Unfortunately, the 
rapid pace of technological breakthrough in computing systems has far 
outpaced developments in computer security. Abuses of computers that 
were not designed from the ground up to provide security currently 
represent a major problem. For these systems, a great need exists for a 
front-end processor to authenticate and control access to the system or 
i ts resources . 

A . HISTORICAL PERSPECTIVE 

In the mid-1950's to the early 1960's, data processing was usually 
confined to a single center. Programs were brought to the computer 
center in the form of card decks. These programs were batch processed 
and any sensitive or classified data could be purged prior to the next 
user. Since there was no sharing of resources, physical security of the 
sensitive or classified data and assurance of a cleared memory were the 
major components of any security policy. 
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As more powerful and -faster computers emerged in the mid-l?60's, 
"operating-systems" evolved to allow multiple users. This was a result 
of the computers'' cost and the fact that human operators were too slow 
to efficiently employ the machines. Simple operating systems selected 
which jobs would run on a priority basis. More dynamic operating 
systems allowed several jobs to run at the same time by the use of 
"multiprogramming". Even more sophisticated yet were operating systems 
that allowed “time-sharing". Many users were allowed access to the 
computer through remote terminals. Although all of these users were 
being serviced at the same time, each user had the illusion of being 
connected to a dedicated computer. The computer was now under the 
control of a computer operating system rather, than the user. These 
privileged operating systems soon became the target of malicious users 
who wanted to penetrate the operating system and share their privileges. 

Suddenly, computer security became an issue. The need for "trustworthy" 

operating systems was apparent. 

B. COMPUTER SECURITY 

"Computer security is the protection of computing assets or 

resources and computer-based systems against accidental and deliberate 
threats whose occurrence may cause losses due to those systems - ' 
non-availability, lack of integrity, or lack of confidentiality." 
[Ref. 2 :p . ?] 

1 . Physical Security 

This is the most basic security requirement and should be 
afforded to all computer systems with considerations given to both the 
internal and external environments. The degree to which physical 



security is insured is dependent upon the value of the data being 
protected. Essentially, most of the considerations given to the 
physical security of computers is not unique to computers and is closely 
related to the security given classified documents. 

2 . Security Modes of Operation 

Information can also be protected from compromise by the 
particular security mode of operation that is selected. The Department 
of Defense recognizes five distinct security modes of operation. These 
modes are enumerated in Appendix A. Security modes of operation fall 
into one of two general categories: dedicated usage or shared resources. 

In the dedicated mode, access to the computer system is 
restricted to an individual user or homogeneous group of users that have 
access to all the information that is processed or stored on the system. 
There is no danger that subversion or failure of the computer will 
result in the compromise of sensitive information. The computer 
security problem in this category is one of physical security and 
personnel screening. 

Resources are most often shared among groups of users with a 
common level of trust to add some flexibility to the dedicated mode. 
Again, physical security and personnel screening are paramount to such a 
security policy and all resources/ term i nal s tied to the system must be 
afforded the same degree of protection. Today's problem is one of being 
able to share computer resources among users or groups of users that do 
not share the same level of trust (multilevel security). 
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3 . Communications Security 



Remote and interactive access to computers give rise to a new 
threat to information security. Information that is being transmitted 
through any medium is susceptible to interception. The most common 
means to combat this threat is data encryption. This technique involves 
the use of encryption algorithms usually seeded by some variable key to 
produce un i n te 1 1 i gbl e code prior to transmission. This code can then oe 
deciphered upon receipt. 

Although not strictly a communications security problem, 
emanations security (TEMPEST threat) is mentioned at this point because 
the same principles of sending and receiving electromagnetic signals are 
involved. Emanations are electromagnetic energy by-products of 
computing devices that are usually most severe when communicating with 
peripherals. These emanations can be detected by sensitive devices for 
several hundred yards. Cathode ray tubes (CRT's) are especially noted 
for their signatures. Protection, such as shielding, is technically 
simple but often awkward and expensive and operationally complex. 

4 . Au then t i cat i on 

Authentication systems have been in use for a relatively long 
time. They are absolutely essential as an access controller in an 
environment of shared resources. The most commonly used is that of the 
password. "The password serves essentially as a "combination" to a 
"lock" allowing access to the system." [Ref. l:p. 274] This type of 
approach is particularly vulnerable when simple passwords are used, 
compromise of the password is allowed, or a computerized password 
generator is used to determine the password (especially if the system 
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does not time out after a number of attempts). Finally, this type of 
access control permits or prevents access to the computer system, but it 
tails to distinguish between the various authorized users. This 
function is dependent upon the internal controls ot the computer itself. 

This technical weakness can be overcome by the development of a 
we 1 1 -f ormu 1 ated security policy that is conveyed to the system 
designers. The system can then enforce access control mechanisms based 
on the authorizations it has been given. A trusted system is the result 
when this process has been successfully accomplished and a well-defined 
policy regarding access to sensitive information is enforced by the 
system . 

The main requirement for a security policy that is to be 
integrated into a trusted system is the need for security "labels" for 
all information to indicate its sensitivity and for all users to 
indicate their authorization for access. Recent research has shown that 
an effective labelling policy can be implemented with a two-part label. 
"The first part represents a hierarchical sensitivity level, such as 
confidential, secret or top secret; the second, user community of 
interest or compartment label." [Ref. 1 s p . 275] 

An operating system must maintain these labels internally =q 
that it can enforce the security policy. The technology is currently 
available, along with mathematical models and formal specifications, to 
accomplish this task. The most predominant approach is that of the 
security kernel (to be explained later). Honeywell Information Systems, 
Inc. and Gemini Computers, Inc. are on the cutting edge of this 
technology and are among the few vendors actively marketing such trusted 
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systems. This paper concentrates on these trusted systems and their use 
as a multilevel security system and/or a secure guard. 

C. DEVELOPMENT OF MULTILEVEL SECURE SYSTEMS 

The need tor systems that can provide a multilevel secure 
environment have been well established as a result of the advent of 
distributed computing systems and shared resources. Alternatives 
(benign environment or "system-high" concept) to such systems are 
unacceptable for many Department o-f Defense applications. The 
alternatives to a multilevel secure system are defined in DoD Directive 
2500.28: 

a. clearing all users to the highest level of information on 
the system and processing all work at that level, or 

b. processing jobs of different levels at different times - 
requiring a complete system change or sanitization each time 
the level is changed. 

A system operating in either of these unilevel modes is usually 
operating "system high." Either of these choices is inefficient and 
costl y . 

In 1968-1974, "Tiger Teams" were formed to attempt penetration of 
access control mechanisms of existing operating systems. Remarkably, 
penetration was accomplished on every commercial operating system. The 
research community became so concerned that public awareness was 
heightened and such issues were the impetus for the development of the 
security kernel which provides the basis for multilevel security. 

In 1972, the Air Force Electronic Systems Division <ESD) conducted 
an in-depth analysis of the requirements for a security system. The 
basic concept of a reference monitor or a security kernel was the 
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result. This concept was the -foundation -for work at the Massachusetts 
Institute o-f Technology, the MITRE Corporation, and Honeywell 
Information System to begin restructuring the MULTICS operating system. 

In 1977, the Department o-f Defense initiated an effort to produce 
the DoD Kernel ized Secure Operating System (KSOS) which would emulate 
the UNIX operating system. The UNIX operating system was chosen because 
of this operating system's use on the popular PDP-11 series of 
computers. The implementation phase was contracted out to the Ford 
Aerospace and Communications Corporation in May, 1973. This project 
became known as KSOS— 1 1 and further development of the operating system 
was oriented towards the DEC PDP-11/70. 

In a joint effort with the Air Force, Honeywell Information Systems 
began developing KSGS-6 in October, 1977. This effort was a 
continuation of the restruc tur i ng of the MULTICS operating system. 
Research was stop and go based on budgetary and other limitations. 
However, a standard commercial product called the Secure Communications 
Processor CSCOMP) was the final result. The system is based upon 
Honeywell's DPS 6 16-bit minicomputer and the MULTICS operating system. 
SCOMP has been verified by the DoD Computer Security Center as having an 
A1 level of security. A discussion of the DoD Computer Security 
Center's criteria for the various levels of security will be presented 
in Chapter 3. 

One of the latest systems to be fielded is the Gemini Trusted 
Multiple Microcomputer Base by Gemini Computers, Inc. A mi crocompu ter 
was chosen as the base because it holds great promise serving as a 
front-end processor because of its physical separation and its small 
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operating system. In the role as a front-end processor tor 
communications, it can easily handle encryption, decryption, and sending 
and receiving. This system is currently being evaluated for a B3 level 
of security and will be discussed later in this paper. 

Much research on multilevel secure and guard systems was acne 
concurrently with the above efforts and much has been done since. For- a 
more complete look at these and other efforts, refer to Appendix C 
[Ref. 3s pp. 90-931. This information is current as of July 1933. 

D. OBJECTIVES 

The primary objective of this paper is to serve as a reference on 
the concept of multilevel security for students in the Command, Control, 
and Communications curriculum at the Naval Postgraduate School who will 
conduct research on the Gemini Trusted Multiple Microcomputer Base that 
is scheduled to be purchased for the W.A.R. lab during the current 
fiscal year. Additionally, an investigation will be conducted to 
determine the utility of this system (other than research) in the lab. 

Since the reference monitor concept (and specifically the security 
kernel) is the most widely accepted model for multilevel systems, a 
discussion of the design and implementation of such models will be 
presented. This discussion details the requirements for the security 
kernel and presents various verification techniques. 

The combination of hardware and software for the purpose of 
enforcing a security policy is the basis for the trusted computer system 
or network. The criteria established by the Department of Defense 
Computer Security Center for evaluating these trusted systems is 
examined in detail since they have tremendous impact on all computer 
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systems and networks in the Department of Defense that process or store 
sensitive i n -format ion. 

Much of the information concerning trusted computer systems and 
networks is necessary -for the understanding of the discussion of risk 
assessment. Risk assessment is an attempt to evaluate the level of risk 
inherent to a system based upon the computing environment. Two methods 
of risk assessment will be compared and contrasted. Risk assessment 
usually involves determining the security level of the user and the 
sensitivity of the information that is being stored or processed on a 
system. Throughout this paper the term "security level" will be used to 
denote the combination of clearance (or classification) and formal 
compartment (or category set). Appendix B lists the security clearances 
currently recognized by the DoD Computer Security Center. 

Finally, a risk assessment of the Wargaming, Research, and Analysis 
(W.A.R.) Lab will be presented. These findings will help support an 
investigation of the integration of the Gemini Trusted Multiple 
M i crocompu ter Base into the W.A.R. lab . 
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II . SECURITY KERNEL DESIGN AND IMPLEMENTATION 



A review of design and implementation guidelines -for the security 
kernel is relevant -for any discussion o-f multilevel security. Most 
experts agree that, at the present time, the security kernel concept 
(introduced by Roger R. Schell in 1972) is the most viable approach to 
meeting security requirements wherever the need exists for a system that 
processes shared in-formation. In 1974, MITRE successfully tested a 
security kernel consisting of only twenty primitive subroutines to 
manage physical resources and enforce protection constraints to prove 
that this concept was valid. 

A. THE REFERENCE MONITOR CONCEPT 

The security kernel approach is based on the reference monitor- 
concept adapted from the models of Butler Lampson (Figure 2.1) [Ref. 4: 
p. 15]. “A reference monitor is a computer system component that checks 
each reference by a subject (user or program) to -an object (file, 
device, user, or program) and determines whether the access is valid 
under the system's security policy. To be effective, such a mechanism 
must be invoked on every reference, must be small enough so that its 
correctness can be assured, and must be tamperproof." [Ref. 3:p. 88] 

The security kernel can best be described as the hardware and 
software that transforms the abstract concept of a reference monitor 
into the reality of a functional security system (Figure 2.2) [Ref. 4: 
p. 17]. During the design and implementation of the security kernel, 
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Figure 2.1 - Re-ference Monitor 




Figure 2.2 - Structure ot a Kernel-Based Operating System 
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total adherence to the -following three engineering principles must be 
observed - completeness, isolation, and verifiability. Every access to 
system information must be mediated by the kernel (completeness). The 
kernel must also be sufficiently protected to prevent tampering 
(isolation). Finally, there must be a close correlation between the 
formal security policy and the effectiveness of the security kernel 
(verifiability). The completeness and i sol at i on requ i remen ts are best 
met with hardware foundations and verifiability strengthened by a formal 
development methodology [Ref. 4:p. 151. 

When the need for a "secure" system arises, a list of demands that 
would insure the desired level of security must be established. Once 
this has been accomp.l i shed , these demands provide the basis for the 
establishment of a formal security policy. All the permissible modes of 
access between all subjects and objects must be addressed. These steps 
must precede the development of a kernel-based system and this formal 
policy is a primary distinction between the security kernel-based system 
and other efforts to develop security-relevant operating systems. 
Concisely, the development of the security kernel-based system 
encompasses both policy and mechanism. 

The security policy is best described by a set of mathematical 
relationships which provide the basis for a formal security model. In 
order to be sufficient, the model must define the overall protection 
behavior of the system as a whole and present a “security theorem" to 
insure that the behavior of the model always complies with the security 
requirements of the applicable policy [Ref. 4 : p . 15]. The policy must 
also address both discretionary access rules (applicable to all users) 
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and nondiscretionary access rules (optional rules applicable to certain 



users) . 

1 . The Bell and LaPadula Model 

The model most widely used -for security kernel development is 
referred to as the Bell and LaPadula model which is the product of early 
security kernel work at MITRE and Case Western Reserve University. This 
model represents the kernel as a finite state machine and defines rules 
for allowable transitions from one secure state to another. Within the 
model, an access class (a security identifier) is assigned to each 
subject and object of the reference monitor. Allowable access to 
objects is made by comparing the access class of both subjects and 
objects at each transition state. The access classes are organized in a 
mathematical structure called a lattice or protection matrix. The 
lattice arrangement defines relationships among the access classes to 
determine if one access class is greater than, less than, equal to, or 
not comparable to another class. 

Figure 2.3 [Ref. 5:p. 212] shows a hypothetical representation 
of a protection matrix access diagram located within a security kernel. 
In this example, User B is considered to be the system administrator. 
It is clear that his privileges far exceed those of User A. Also, this 
representation shows that other programs or functions, such as the 
Editor Command Module, are allowed to operate within established limits. 
Such an access matrix must reside in the security kernel to insure its 
i n tegr i ty . 

The model contains two fundamental nond i scr e t i onary rules - 
simple security condition and ^-property. The simple security condition 
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Figure 2.3 - Protection Matrix Access Diagram 
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allows a subject at a given security level to have read access only to 
objects at the same or lower security levels (no read up). Simply 

stated, this rule prevents unauthorized personnel from directly viewing 
information for which they do not have proper access. The ^-property 
prevents a subject from having write access to objects at lower security 
levels (no write down). This rule was established to combat "Trojan 

horse" software and prevents users from unauthorized indirect viewing of 
i nf orma t i on . 

The model also includes rules to protect the integrity of the 
system's information and to prevent improper alteration. Subjects of 
one access class cannot alter objects located in a higher class. 
Conversely, a subject of one access class cannot be altered by objects 
of a lower access class. 

Provisions also exist in the model for discretionary access. 

Authorized users and programs can arbitrarily grant and revoke access to 
information based on user names or other information. 

One limitation of the Bell and LaPadula model, as with most 

other models, is the lack of safeguards against denial of service. 
Denial of service is the threat of intentional or unintentional 
disruption or degradation of service. However, the inclusion of a 
security kernel does not affect the system's susceptibility to the 
threat of denial of service. This shortcoming is attributable to the 
difficulty of establishing a mathematical model to represent the rules. 
B. THE DEVELOPMENT PROCESS 

Once a security policy has been formalized and an appropriate model 
has been selected, the development process must be divided into small 
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increments -for implementation. “One common technique is to apply a 
hierarchy of abstract specifications to the design of the security 
kernel. For each step, it is important to demonstrate security so that 
we haue confidence in the security of the final system." [Ref. 4sp. 1<S3 
Figure 2.4 is a depiction of the ' i ntegrat i on of the model, the hierarchy 
of specifications, and the h i gh — level language implementation [Ref. 4: 
p. 171. 

Three classes of formal verification techniques during the kernel 
development process are also shown in Figure 2.4. The first class is 
used to prove that the kernel responds as outlined in the formal 
high-level interface specification. Security flow analysis is often 
used to analyze information flow in a specification. The second class 
of verification tests the correctness of mappings between intermediate 
specifications in the hierarchy and interface specifications. The third 
and most traditional technique is the verification of implementation to 
spec i f i cat i on . 

The kernel provides a relatively small subset of the operating 
system's functions. The kernel primitives that provide the interface of 
this subset to the remainder of the operating system are often referred 
to as the supervisor. General-purpose operating system functions used 
by the applications are provided by the supervisor primitives. 

Functional areas such as process management, file system management 
for segments, and I/O control comprise the operating system. Each of 
these areas possibly have security relevant functions that must be in 
the security kernel. The policy model should identify these security 
relevant functions. Of particular importance is the kernel's role in 



25 




Figure 2.4 - Development and Verification Hierarchy 



26 




managing system resources such as memory and disk space that are shared 
by multiple users. These -functions are located in the kernel because 
they must be virtual (realized by the combination o-f hardware and 
so-ftware) in order to hide their location -from untrusted so-ftware. It 
is permissible -for any utility controlling anything not shared by users 
to be located outside the kernel (in the supervisor). 

The basic security model that has been described thus -far is 
rudimentary and most likely the greatest need exists -for a system that 
can be tailored to meet specific requirements that may change -from time 
to time. A kernel that is written so that it is adaptable usually has a 
group o-f inter-faces that can be invoked by i ndi v i dual s/programs with 
special privileges - trusted subjects. Internal identi-fiers such as 
privilege indicators allow actions such as certain system maintenance 
activities and access control -for nontrusted subjects (Figure 2.2) 
[Re-f. 4 : p . 171. Trusted subjects utilize trusted processes and trusted 
-functions to per-form such routine tasks as maintenance o-f the system's 
access roster and the upgrading or downgrading o-f classified material 
when appropr i ate . 

1 - Security Kernel Design and Implementation 

The design of the security kernel can approach two extremes when 
considering the degree to which the kernel implementation is to be 
founded in hardware. At one extreme, the kernel is entirely written in 
software and can be run on any conventional machine. In this case, the 
kernel interprets every user instruction and disallows direct user 
instructions to hardware. The only hardware involvement is its 
execution of the kernel software. The other extreme is the total 
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implementation of the kernel as hardware instructions which places 
absolute responsibility for security on system arch i tec t ure . Obviously, 
tradeoffs must be made between hardware and software with respect to 
complexity, size, and performance. 

Specific hardware and software mechanisms from four general 
architectural areas have contributed to varying degrees to supporting a 
kernel-based general-purpose operating system. These four architectural 
areas are: explicit processes, memory protection, execution domains, and 
I/O mediation [Ref. 4 : p . 183. 

Explicit processes refer to the need for support for multiple 
processes (multiprogramming) and interprocess communications. Access 
decisions for subjects are made on the basis of the user's 
identification and access class. These two identifiers must be 
impossible to counterfeit and are tied to each process. In a* on-line 
system, multiple users must be serviced, thus the kernel must support 
multiple simultaneous processes. This creates the need for a greater 
number of process switches and makes efficient process-switching 
mechanisms such as high speed memory more desirable. 

Memory protection requires large segmented virtual memory, 
access control to memory, and explicitly identified objects. Memory is 
the usual realization of the reference monitor concept of storage 
object. Virtual memory and the use of some form of descriptor are 
commonly used together to serve as an interpretive mechanism to mediate 
all access to memory. 

All information within the system must be represented by 
distinct, identifiable objects. The virtual address space of an object 
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includes more than one object. Each has its own distinct logical 
attributes such as size, access mode, and access class. This logically 
distinct memory is called a segment. 

Virtual memory segmentation is usually supported by hardware. 
The mapping -for segments to virtual address is controlled by a 
descriptor. This descriptor has not only logical attributes but 
contains both a physical base address and a segment size which uniquely 
identities each segment. The segment descriptor must support the access 
modes o-f at least null, read, and read-write -for each segment in order 
to provide adequate discretionary and nondiscretionary access policies. 
These segment descriptors are managed by the security kernel software. 
However, the address-mapping hardware still plays a significant role- in 
the actual access mediation process. 

Although access to segments is dependent upon unique 
descriptors, the possibility o-f an unintentional leakage of in-formation 
by use o-f control in-formation such as -file names and attributes and 
system variables maintained within the kernel database still exists. 
Strict design and ver i f i cat i on techniques can prevent or detect this 
de-ficiency. The discovery o-f such a leakage channel late in the 
kernel 's development is a -formidable problem -for the kernel designer-. 

Execution domains are necessary -for the isolation and 
protection o-f the security kernel mechanism. In order -for security 
kernel functions to be invoked, the total address space of the process 
must include the programs and data of the security kernel. When the 
process must access segment descriptors, it is necessary for this 
execution to take place in the kernel only. This requires a separate 
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execution domain -for the security kernel. It is also desirable to keep 
the supervisor separated -from the applications software, A domain 
structure with three hierarchical domains (kernel, supervisor, and user) 
is necessary to keep the user and the operating system separated. 

Efficient transfer of control between domains is a desirable 
feature because of the vast number of calls a process makes to the 
kernel and the supervisor. Access to the most privileged domains of the 
system must be characterized by a few, carefully defined entry points or 
security will reduce speed dramatically. 

Input/Output mediation can best be handled by a hardware 
architecture <e.g., I/O processor) that allows direct user or supervisor 
domain access to I/O. This requires the use of a descriptor to control 
access to devices similar to the descriptors used for access to memory. 

2 . Verification 

The final comment about security kernel design and 
implementation concerns verification. Verification technology has not 
fully matured and is limiting. At the present time, the greatest degree 
of success has been associated with specification verification such as 
the flow analysis method mentioned earlier in Section B of this chapter. 
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Ill . POD TRUSTED COMPUTER SYSTEMS AND NETWORKS 



Two publications having possibly the greatest impact on multilevel 
security in computers and distributed systems of computers or networks 
are products o-f the Department o-f De-fense Computer Center located at 
Fort Meade, Maryland. They are the Department o-f De-fense Trusted 
Computer System Evaluation Criteria (CSC-STD-001-83) dated 15 August 
1983 and the Department o-f De-fense Trusted Network Evaluation Criteria 
(currently in Draft) dated 29 July 1985. These two publications will be 
discussed in some detail since the blueprint for all acceptable systems 
must conform to these criteria and the current vernacular of trusted 
systems can be traced to these documents. 

A. TRUSTED COMPUTER SYSTEMS 

The publication, Department of Defense Trusted Computer System 
Eval uation Criteria was written by the Department of Defense Computer 
Security Center in accordance with DoD Directive 5215.1, "Computer 
Security Evaluation Center." The purpose of document is to establish a 
“uniform set of basic requirements and evaluation classes for assessing 
the effectiveness of security controls built into Automatic Data 
Processing (ADP) systems." [Ref. 6i p. i] Any ADP system used for the 
processing and/or storage and retrieval of sensitive or classified 
information by the Department of Defense is to be evaluated using the 
criteria defined in the document. This publication is commonly referred 
to as the "orange book." 
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Many of the criteria presented in this publication originated from 
work done by the MITRE Corporation and the National Bureau of Standards 
(NBS) prior to the formation of the DoD Computer Security Center in 
January 1981. These standards fulfill two distinct sets of require- 
ments: 1) specific security feature requirements; and 2) assurance 
requirements. The specific security features are primarily oriented 
towards information systems employing general-purpose operating systems 
rather than applications programs being supported. The assurance 
requirements are applicable for all computing environments ranging from 
dedicated controllers to full range multilevel secure resource sharing 
systems [Ref . 6 : p .2] . 

1 . Fun dame n t al Requ i remen ts 

A secure computer system must limit access to information and 
allow properly authorized individuals or their appointed repr esena t i ves 
only to read, write, create, or delete information. Six fundamental 
requirements are presented as absolute essentials in obtaining such a 
secure system. Four of these requirements deal with the actual needs to 
be provided to control access to information and two deal with 
assurances that this access to information is in fact being controlled 
and that a trusted computer system exists. 

The first two requirements involve an organization's policy 
towards computer security: 

Requirement 1 - Security Policy 

The system must be capable of enforcing an explicit and 
well-defined security policy to insure that only personnel with proper 
access (to include d i scr e t i onar y access) are allowed access to the 
system. Security policy design should be influenced by the perceived 
threats, risks and goals of the organization. 
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There are two types of security policy to be considered: 
mandatory security policy and discretionary security policy. Mandatory 
security policy establishes a set o-f rules that permits or denies access 
to material based directly on the individual's clearance or 
authorization. Discretionary security policy takes the permission or 
denial o-f access one step -further and is the principal type o-f access 
control available in computer systems today. Not only must an 
individual be authorized access to in-formation, but a need-to-know 
requirement must also exist. It is important to note that a 
discretionary policy is to be developed in addition to the mandatory 
policy and not as a substitute. 

Requirement 2 - Marking 

Objects must be marked with access control labels that con-form 
to the mandatory security policy. These labels must identity the 
sensitivity or cl ass i -f i cat i on o-f the object and the mode o-f access -for 
authorized users. Whether used internally or as output, accuracy and 
integrity o-f the security labels is paramount. 

The third and -fourth requirements are concerned with 
accountabi 1 i ty : 

Requirement 3 - Identification 

The computer system must be able to mediate access to 
information by identifying authorized users and determining their level 
of clearance and their need-to-know. Once identification of the user 
has been established, there must be a means of authentication. 

Requirement 4 - Accountability 

Audit information must be recorded so that all transactions 
affecting system security can be traced to the responsible party. This 
information log must be protected from'any tampering that would alter or 
delete such an audit trail. 

The final two requirements involve assurance that the computer- 
system is secure: 

Requirement 5 - Assurance 

The computer system must contain hardware/sof tware mechanisms 
that can be individually evaluated to assure adherence to Requirements 
1-4. Two types of assurance are needed: life-cycle assurance and 
operational assurance. 

“Life-cycle assurance refers to steps taken by an organization 
to insure that the system is designed, developed, and maintained using 
formalized and rigorous controls and standards ... Operat i onal assurance 
focuses on features and system architecture used to insure that the 
security policy is unc i rcumven tabl y enforced during system operation." 
[Ref. 6 : p . 601 
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Requirement 6 - Continuous Protection 

The computer system must continuously provide the protection 
outlined in these -fundamental requirements be-fore it can be judged a 
trusted system. 

2 . The Criteria 

The criteria set -forth by this publication are divided into four 
hierarchical divisions; A: Verified Protection, B: Mandatory Protection, 
C: Discretionary Protection, and D; Minimal Protection [Ref. 6: p. 51. 
They are arranged from the highest level of security to the lowest level 
respectively. The step up from one Division to another represents a 
significant increase in security. Divisions B and C are further 
subdivided into classes that are arranged in a hierarchical manner based 
on the security mechanism that they possess. A rating for a particular 
system is based on thorough testing of the security- relevant portions 
of that system. The secur i ty-re 1 evan t portion of the system is spoken 
of collectively as the Trusted Computing Base (TCB) . Each class is 
described by four major sets of criteria; Security Policy, 
Accountability, Assurance, and Documentation. 

Division D: Minimal Protection has only one class and is 
reserved for systems that have been evaluated, but failed to achieve the 
standards of a higher class. 

Division C: Di sere t i onary Protection contains two classes that 
provide discretionary access to information and the means to audit and 
account for such usage. The two classes are: Class Cl: Discretionary 
Security Protection and Class C2: Controlled Access Protection. 

The Trusted Computing Base (TCB) of Class Cl satisfies 
discretionary access requirements by separating users and data. The 
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Class Cl environment is expected to be one of cooperating users 
processing data at the same level o-f sensitivity C Re -f . 6:p. 123. 

Identification and authentication are required to determine authorized 
individual or group users. 

The discretionary control o-f Class C2 is made more positive 
through login procedures, auditing o-f security-relevant events, and 
resource isolation. The emphasis is on the individual user in this 
class. By limiting usage to individuals or groups o-f named individuals 
accountability -for sensitive data is more easily maintained. 

Division B: Mandatory Protection contains three classes that 

are characterized by a Trusted Computing Base <TCB) that preserves the 
integrity o-f the security labels and uses them to enforce a set of 
mandatory access control rules by. using the reference monitor concept 
<eg. a security kernel). These three classes are: Class B1 : Labeled 
Security Protection, Class B2: Structured Protection, and Class B3: 
S'ecur i ty Doma ins. 

Class B1 systems have all the same requirements found in Class 
C2. Additionally, an informal statement of the security policy model, 
data labeling, and mandatory access control over named subjects and 

objects must be present. The capability must exist for accurately 

labeling exported information and any flaws detected by testing must be 
corrected [Ref. 6: p. 203. 

In contrast to Class B1 , Class B2 requires the presence of a 
formal security policy clearly stating both mandatory and discretionary 
access controls. The TCB enforces a more rigid authentication 

mechanism. This is the first level that addresses covert channels - a 
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communication channel that allows the transfer of in-formation in such a 



manner that violates the system's security policy. Systems con-forming 
to Class 82 requirements are considered to be relatively resistant to 
penetrat i on . 

Class B3 must include a re-ference monitor that will mediate all 
user access to system in-formation, be tamperproof , and be small enough 
•for exhaustive tests and analysis. Security administration is supported 
and audit mechanisms are expanded to signal all security-relevant events 
with recovery procedures required. Class 83 systems are considered to 
be highly resistant to penetration. 

Finally, Division A: Verified Design presently contains one 
class - Class A1 : Verified Design which has the most rigid security 
requirements given the state of current technology. Extensive 
documentation is required on the TCB to demonstrate the ability to 
conform to security requirements. Systems in this class are 
functionally equivalent to Class B3. There are no architectural 
features or policy difference. The significant highlight is the added 
emphasis on formality in this class. Formal security verification 
methods are required to assure that both mandatory and discretionary 
access controls protect all classified or sensitive information either 
stored or processed on the trusted system. 

Figure 3.1 [Ref. 6:p. 107] summarizes the trusted computer 
system evaluation criteria requirements for each classification. 
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NO REQUIREMENTS FOR THIS CLASS 



B. TRUSTED NETWORK SYSTEMS 



The second DoD Computer Security Center publication previously 
mentioned currently exists in draft form only. The document is 
entitled, Department of Defense Trusted Network Evaluation Criteria , 
dated 29 July 1985, and is the logical complement to the DoD Trusted 
Computer System Evaluation Criteria . 

The criteriawere first established for computer systems in 1983, 
but it was soon realized that there were unique risks associated with 
distributed systems or networks that needed to be addressed separately. 

Distributed computer systems or networks are composed of a set of 
nodes, communications lines connecting these nodes, and a set of rules 
(protocol) to facilitate the network's operation. A node is usually 
composed of a communications processor (switch) and at least one host 
processor. At one extreme, a single processor may serve both the 
communications and host f unc t i ons . * On the other, each function may be 
performed by mu 1 t i processors . A typical node configuration may include 
a communications processor, a host, and a network front-end processor 
(NFEP) which may perform both pre- and post- processing for the host. 

Establishing a security policy for a distributed system is a far 
greater task than in a centralized system. Security in the distributed 
system is only as strong as the quality of the enforced security policy 
at any one node and a breach of security at one node can have grave 
implications for other nodes in the system. An environment exists where 
users interact with host systems via remote access terminals in a real 
time fashion where data can be accessed, read, altered, or destroyed in 
a very rapid manner. Often these remote terminals are in a more hostile 
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environment than the host and the user is -free -from administrative and 



operational controls. 

Certainly, the security issues of distributed systems are more than 
the union of the security issues of communications and computer systems. 
These issues address a unique threat of leakage or loss [Ref. 8:p. 301: 

1. The physical security problem extends beyond the physical 
environs of host computer's location. 

2. The communications lines are vulnerable to tapping or 
passive monitoring of emanations. Crosstalk between 
communications lines or within the switching centrals can 
present a vulnerability. 

3. A large population of users with varying clearances and 
need-to-know authorizations interact simultaneously on the 
network system. 

4. The probability of system error and vulnerability to 
intrusion becomes greater as the size of the network 
increases. 

5. Exhaustive testing and verification of software to determine 
if errors or anomalies exist is not possible for large 
software systems. 

6 . The identification of a user located at a remote terminal or 
facility is more difficult. 

The Trusted Network Evaluation Criteria is divided into two parts: 
Trusted Network Criteria, applied on a global network-wide basis, and 

Trusted Network Component Criteria, applicable to individual network 

components. Both parts are closely linked and many of the criteria are 
derived from the "orange book." 

Again, there are four hierarchical divisions of enhanced security 
protection. These divisions are delineated with respect to the three 
issues of data compromise, erroneous communications, and denial of 

service. Since different hardware and software are likely to be used 



39 



within network systems, a separate evaluation should be conducted in 
each area. 

For a network to be assigned a division rating -for data 
compromise, erroneous communications, or denial of service the network 
must satisfy all Trusted Network Criteria for that division and all of 
its trusted components must satisfy at least the equivalent division 
requirements of the Trusted Network Component Criteria. Limited by 
technology, criteria for erroneous communications and denial of service 
are yet to be defined for the most rigid security division, NA. 

A reference model such as the International Standards Organization 
Open Systems Interconnection (OSI) Model or its equivalent must be 
established for comparison purposes when evaluating a network. “The 
hierarchy of protocols to be used within the network by host computers 
and network components must be specified, as well as the location and 
content of any secur i ty-r e 1 evan t information contained within those 
protocols, such as security labels. A direct correspondence must be 
shown between the secur i ty-re 1 evan t portions of these communications 
protocols and the security features employed in the trusted components." 
[Ref. 7 : p . 4] 

1 . Fundamental Requ i remen ts 

The six fundamental requirements listed previously for a 
"secure" computer system can be extended for applicability to the 
"secure" network with little modification - four dealing with what needs 
to be done to control security in a trusted network and two dealing with 
credible assurances that these requirements are met. 



40 



2 . The Criteria 



Again, the Trusted Network Criteria de-fine the minimum set o-f 
global security -features and assurance requirements to be met by the 
Trusted Network Base (TNB) . There are many parallels between the -four 
hierarchical divisions o-f the Trusted Network Criteria and the Trusted 
Computer Systems Evaluation Criteria. The -four divisions are Division 
ND, Division NC, Division NB, and Division NA. Significant additions 
having relevancy to trusted network systems will be discussed. 

Division ND: Minimal Protection is reserved -for those systems 

that have been evaluated but -failed to meet the requirements for a 
higher evaluation division. Minimum security results and there are no 
security -features to protect against data compromise, erroneous 
communications, and denial o-f service. 

Minimal data compromise, erroneous communications, and denial o-f 
service are indicative o-f Division NC: Controlled Access Protection. 

Security decisions based on the classification of information are 
handled administratively; thus, networks within this division are not 
required to make security decisions based on the classification of 
objects and subjects. Network compromise protection is achieved through 
the use of techniques such as resource isolation within network 
components, data encryption, or physical protection of the 
communications medium. Network discretionary access control is defined 
by the Trusted Network Base (TNB) and uses enforcement mechanisms such 
as closed user groups and network access control lists to include or 
exclude access with the focus on the single network subject. The 
following documentation is also required for this division: Network 
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Security Features User's Guide, Trusted Network Facility Manual, Network 
Test Documentation, and Network Design Documentation. 

A documented, -formal security policy model that requires 
mandatory access control en-forcement over all network subjects and 
network objects and which addresses the issue o-f covert channels must 
exist -for networks within Division B: Mandatory Protection. TNB design 
and implementation require more thorough testing and more complete 
review. The TNB must maintain sensitivity labels -for all network 
resources that can be accessed either directly or indirectly by subjects 
external to the TNB. These labels are to be used as the basis -for 
access control decisions. “The TNB shall support a trusted 
communication path between network subjects -for use when positive 
component to component communication is required (e.g., initialization, 
encryption key management, change o-f network subject security level (s)). 
Communications via this trusted path shall be activated exclusively by a 
network subject or the TNB and shall be logically and unmistakably 
distinguishable -from other paths." [Ref. 7:p. 1?] The same documents 
are required as in the previous level; however, a more -formal 
description o-f the network's resources and test results is needed. 

Division NA: Verified Design requires networks to possess a 
reference monitor that mediates all accesses of subjects to objects, be 
tamperproof, and the distributed portions of the TNB to be small enough 
to be subjected to analysis and tests. Formal design specification and 
verification techniques assure that the TNB is correctly implemented. 
There are two types of formal specification - "formal policy model" and 
"formal top level specification (FTLS)" . The "formal policy model" is 
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used to analyze a complete network and must be demonstrated by a 
mathematical proof that it supports the security policy. The “formal 
top level specification <FTLS)" deals with the detailed functionality of 
the network and must be consistent with the model by formal verification 
techniques. Formal analysis techniques must be used to identify and 
analyze covert channels. 

The Trusted Network Component Criteria are detailed to establish 
the minimum set of security features and assurance requirements that 
each component must meet in order to insure that the global Trusted 
Network Base <TNB) requirements can be achieved. These standards are 
treated in the same manner as the aforementioned Trusted Network 
Criteria; thus, little purpose is served by pointing out the specific 
requirements of each division <see Reference 7 for more details). 
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IV. RISK ASSESSMENT 



The purpose o-f multilevel security is to provide cost-eff ec t i ve 
coun t ermeasur es to protect a system -from the many threats which exist. 
These countermeasures must reduce the -frequency and impact of threats 
upon the system, provide for contingency planning when the system s 
operation is disrupted, and audit the system in both the normal and 
standby modes of operation. The problem of weighing the risk of the 
loss threatened with the cost of effective countermeasures gives rise to 
the imprecise science of risk management. A brief discussion of risk 
management in general will be followed by a look at the methodology set 
forth by the DoD Computer Security Center for assessing a system's 
inherent risk and at an approach suggested by Carl Landwehr and H. 0. 
Lubbes of the Naval Research Laboratory in Washington, D.C. 

A. RISK MANAGEMENT 

Risk management involves the manipulation of various tools and 
techniques tailored to meet a specific need in the prevention of 
unauthorized intervention in the various levels of a system's operation. 
However, the methodologies employed are basic [Ref. 9:p. 261 : 

a. Threat identification 

b. Threat impact measurement 

c. Coun termeasur e identification and measurement 

d. Countermeasure selection 

e. Implementation and monitoring of safeguard effect 
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Historically, risk managers have measured the cost-e-f -f ec t i veness o-f 
security measures taken in terms o-f dollars. This has led to greater 
concern over those threats that cause total or near total destruction o-f 
the system (e.g., natural causes, gross errors, omissions). I-f 
reasonable security measures have been taken, many o-f these threats 
<e.g., errors and omissions) have a greater probability o-f occurrence 
than penetration o-f the system by an unauthorized source . It is also 
di-f-ficult to determine the "cost" o-f compromised classi-fied in-formation 
(assuming that a penetration has been detected). However, once the 
commitment is made to develop multilevel trusted systems, greater access 
to systems by users o-f varying levels o-f clearances and need-to-know 
authorizations increase the risk o-f compromise. The need still exists 
-for sa-feguards against the traditional concerns, but the threat o-f 
unauthorized penetration must be given much greater attention when the 
secrets o-f a nation are at stake. The DoD Computer Security Center has 
developed a scheme -for assessing the risk in trusted systems. 

B. RISK INDEX 

The evaluation classes described in the DoD Trusted Computer System 
Evaluation Cr i ter i a are primarily based on the level o-f security risk 
inherent to a particular system. Another DoD Computer Security Center 
publication, Technical Rationale Behind CSC-STD-QQ3-35 : Computer 
Security Requirements — Guidance -for Applying the Department of Defense 
Trusted Computer System Evaluation Criteria in Speci-fic Environments , 
presents a methodology -for assessing a system's inherent risk - the 
"risk index." "The risk index can be de-fined as the disparity between 
the minimum clearance or authorization o-f system users and the maximum 
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sensitivity of data processed by a system." [Re-f. 1 0 : p . 53 Although 

other -factors can in-fluence security risk, the risk index is uniformly 
applied in the determination o-f security risk and is the only basis -for 
determining the minimum class o-f trusted systems. 

The risk index is computed by comparing the system's minimum user 

clearance <R m j n ) -from Table 4.1 [Re-f. 10:p. <£3 with the system's maximum 
data sensitivity (R max ) from Table 4.2 [Ref. 10:p. 73. The 
relationships for the actual computations follow: 

Case I. If Rjnin is less than R,^.^ then the Risk Index is 
determined by subtracting R m j n from R max : 

Risk Index = R max - R^ 

(This equation works in all cases but one. When the 

minimum clearance is Top Secret/Background Investigation 

and the maximum data sensitivity is Top Secret, the Risk 

Index should be 0 rather that the computed value o-f 1.) 

Case II. I-f R m j n is greater than or equal to R max , then: 

I 1 , i -f there are categories on the system 

Risk Index = I to which some o-f the users are not 

I authorized access. 

I 2, otherwise (i.e., i-f there are no 
Risk Index = I categories on the system or i-f all 

I users are authorized access to all 

I categor i es) . 

Table 4.3 [Re-f. 10:p. 83 is a matrix o+ computed security risk 
indexes -for categories associated with maximum data sensitivity levels 
above Secret. I-f local authorities -feel that the environment has 
additional risk -factors a-f-fecting system security, a larger risk index 
can be assigned. 
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TABLE 4.1 



RATING SCALP! FOR MINIMUM USER CLEARANCEl 



MINIMUM USER CLEARANCE ' 


RATING 

(Umin) 


Uncleared (U) 


0 


Not Cleared but Authorized Access to Sensitive Unclassified 


1 


Information (N) 




Confidential (C) 


2 


Secret (S) 


3 


Top Secret (TSVCurrent Background Investigation (BI) 


4 


Top Secret (TS)/Current Special Background Investigation (SB!) 


5 


One Category (1C) 


6 


Multiple Categories (MC) 


7 



J See Apppendix B for a detailed description of the terms listed 



